home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 13.7 KB | 225 lines | [TEXT/GEOL] |
- Item 9846117 17-Feb-91 13:42PST
-
- From: D3085 Progressive Computing, D Lucky,PRT
-
- To: MACAPP.TECH$ MacApp Technical
-
- ------------------------------------------------------------------------------
-
- Sub: MacApp wish list
-
- To the MacApp development team(s) (and anyone else who cares):
-
- Stuff I'd like to see in MacApp:
-
- 1) Make MacApp more of a true Application Framework. I'd like to see much
- more effort put into the development of generic data structure classes (e.g.,
- trees, graphs, sets, dictionaries, hash tables, bit maps, matrices, etc.).
- Right now, I think of MacApp as an Interface Framework. I spend the majority
- of my time building the data model and its behavior. The List and SortedList
- classes are nice for small numbers of nodes or elements but are not efficient
- for larger numbers of nodes. (By the way, with the current level of
- documentation and without source code, I would have never guessed that a TList
- is really an array of fancy node references... I originally thought Lists were
- linked lists and couldn't figure out how binary searches were done on
- SortedLists.) Also, I'd like to see some of the current data classes
- generalized. I was surprised to see that TAssociation is really a relationship
- between two strings instead of two objects.
-
- 2) Models (both internal and external). An internal model represents the core
- behavior of my system. It does not have any user event handling capabilities
- of its own (such as DoXCommand). It does, however, provide interfaces to those
- that do handle user events. This means that, if the need arises, I can move my
- model to another application (possibly on another platform… did I say that?).
-
- The external model provides persistency (is that really a word?) across
- invocations of the program. This allows me to be able to save the model in
- different ways for different applications. Also, this let's me start with a
- primitive way of saving the objects initially and let's me move to a database
- solution later in the game if necessary. In my scheme, the external model has
- intimate knowledge of the internal model but the internal model doesn't know
- anything about the external model.
-
- TDocument as it currently exists comes close to being the class for the model
- but it also contains user event handling. I'd like to see the current
- TDocument pruned to just handle model-related (both internal and external) user
- events. Also, I'd like to see the management of views removed from TDocument.
- It can, however, keep the behavior for creating windows when opening the
- document and destroying windows when closing a document. I'd like to see
- direct knowledge of views maintained only within windows. With the
- introduction of dependencies (described later), windows and views can install
- themselves as dependents of the model or specific objects in the model. I just
- don't see the document needing to have any other knowledge of views.
-
- By the way, I don't ever include rendering fields or methods in my internal
- model. I find that one Draw method doesn't fit all the views that want to
- render the object. The alternative of creating multiple Draw methods or adding
- parameters to the Draw method to figure out how to render the object keeps the
- model in a state of flux as I'm adding views to the application. I want to get
- the behavior of the model working first and then add the user interface. The
- downside of this approach is that I have to create view-type objects that
- represent the model objects. Each view that renders model objects owns a set
- of these view-type objects. This partitioning of a model object into both a
- model object and a view-type object provide a clearer picture of
- responsibilities even though there is memory consumption for object overhead
- for each view-types object created.
-
- What do I gain from all of this? A layered approach to building systems. The
- internal model is the foundation while the external model, document, and views
- are on top. When I add/modify views, change the document, or change the
- external model, then nothing else should be touched unless the internal model
- must be modified to handle those changes. If the internal model changes,
- however, then everything else in the system may have to be modified. I don't
- see this ripple effect, though, as anything more difficult than I do with the
- current MacApp architecture.
-
- 3) Different command structure. I think of a command as a unit of operation.
- In other words, multiple operations may be performed to one or more objects
- with a command. Within each operation, I would like to be able to fire off
- other commands. These nested commands, then, may kick off still more commands
- (ad nauseum). Only the commands that are the furthest nested can actually
- cause a change to an object. For example, I catch a user event through a
- DoXCommand and, just for grins, its an undoable command so I create a command
- object. The undoable command's DoIt now gets control. The purpose of this
- command is to modify two objects. Instead of calling the modification methods
- of those objects directly, I create two new commands. Each of these commands
- has a name that is similar to the object that is being modified. The DoIt
- methods of these two commands are then executed which, in turn, call the
- appropriate modification methods for that object. The creation of these
- "object commands" is extra overhead but I feel that it provides better
- accountability of which commands are the "gateways" to the object and it
- provides for finer granualarity of commands. To make this all work, I'd like
- each command object have a set of commands. This would be easy if I had a set
- class (yea, I know, I could use TList but it's not precise).
-
- If I haven't befuddled you yet, I'll try again. In the example above, I've
- specified two different types of commands: The user event command and the
- model command (i.e., the two nested commands). Since I've advocated this tight
- coupling between commands and the object they modify, it seems that the command
- classes should be integrated into the object classes (e.g., view, model, etc.)
- so objects can be more of a "black box". Kinda sounds like multiple
- inheritance can be used for this purpose. For example, TMyView could inherit
- from TView and TMyCommand. This oughtta drive MacBrowse bananas.
-
- 4) Dependencies (both simple and command). My definition of a simple
- dependency is one where a sponsor object issues a Changed (or some such)
- message to himself which, in turn, issues Update (or some such) messages to
- each of the objects in his dependency set. I then stick my calls to Changed
- within my Set methods. Now every time I modify an object, all of its
- dependents are notified.
-
- Propogating commands seems to be stickier. I'd like to have a way to have a
- sponsor notify dependents to execute a command rather than a simple update.
- There are a few ways to do this. The first is to use a parameter of Update to
- indicate the type of operation (DoIt, UndoIt, RedoIt, Commit). The problem
- here is that I can see the possibilities of some pretty big case statements for
- Update. The second is to have multiple update-type messages. I can imagine
- there are a number of other schemes that can be used.
-
- 5) Use of a language that provides multiple inheritance capabilities and class
- variables and use those capabilities. At this time it's C++. Maybe tomorrow
- it's Pascal 9x. I'll put up with the warts of either language to get this
- capability. I think that it is much more natural to use multiple inheritance
- to design classes than to resort to the present methodology. You know the
- drill. Pick the class with the most commonalities and create a subclass of that
- type. In the initialization routine, create objects of the other classes and
- stash their reference in the object. There are two problems that I have with
- this approach. The first is that it just doesn't seem natural. The second is
- that I have to write little bridge methods for all of methods of the other
- classes unless I break encapsulation by calling the methods of the other
- classes directly (e.g., A.B.Method). Then again, maybe I'm the only one that
- thinks that these sort of method invocations defeats the purpose of "black-box"
- objects.
-
- I'm not much for religion about languages, environments, libraries, operating
- systems, or machines. I like the old saying, "If all you have is a hammer,
- then the whole world looks like a nail." While I'm haven't yet mastered all
- the intracacies of C++, I think it provides much more power and flexibility
- than Object Pascal. It also allows me to hang myself and write some pretty
- rotten code but that's part of my maturation process with a new language. I
- can write cryptic code in any language but one the measures of my skill as a
- software engineer is to write maintainable code (whatever that really means).
- Also, I don't need a mastery of C++ for MacApp 3.0 to understand what's going
- on. All I need is to be able to read the code and understand what's going on.
- That's far different than the mastery of C++ that I need when designing classes
- in C++.
-
- If I have a language choice between C++ and Pascal 9x, then I'll pick C++ for
- purely strategic reasons. If I use C++, then I can choose class libraries that
- run on multiple platforms. If I choose OP/Pascal 9x, then I'm limited to only
- Macintosh libraries. This view might be different if Pascal 9x were to become
- a standard across platforms and had a better selection of class libraries.
-
- 6) Perform iterations over lists differently. Since C++ doesn't have nested
- procedures, coding pascal-type "callback" functions that are the target of Each
- can be extremely painful.
-
- 7) Keep distributing the source. I'd like to see better documentation for the
- MacApp class methods on paper, a more complete cookbook, and more complex
- tutorials but I couldn't tell you the sort of documentation that would be
- required before I wouldn't need the source. I don't, however, think that I
- need to know about fields if you provide me all the methods to interrogate and
- modify MacApp objects.
-
- I'd like the source for a few reasons. First, sometimes I want to really know
- how things are being done. This is a last resort when the documentation
- doesn't tell me what I need to know because I can spend a huge amount of time
- learning the fine details. The second is that I sometimes fix bugs in the
- code. I don't create bug-free code and I don't expect it from Apple. I don't
- believe we've reached the point where we can guarantee code with zero defects.
- My problem is that I sometimes need immediate turn around time for the fix.
- Apple doesn't provide nor do I expect this kind of service. The third reason
- is that I may want to modify the behavior of a MacApp class. I realize that
- Apple cannot be held accountable for any problems I create.
-
- 8) If necessary, provide System 7.0 capabilities in a MacApp 2.x (this number
- used only for a forward reference… the version number doesn't matter to me)
- release done in Object Pascal ASAP. Afterwards, add my recommendations (yuk,
- yuk) as well as your own to the next release done either in C++ or Pascal 9x.
- The change to a new architecture is sure to break everyone's code in any
- language so we can all suffer together. Those that do want a new architecture
- can upgrade and those that don't can continue to use the 2.x version. I fully
- expect that the 2.x version wouldn't be supported by Apple when the next
- release becomes production.
-
- 9) Get the C++ team to include the new parameterized types and exception
- handling mechanisms implemented ASAP. Also, get them to fix the problem with
- multiple inheritance of Handle-type classes. I think I understand why C++
- won't currently do multiple inheritance on these classes but more effort really
- needs to be committed to solving this problem.
-
- 10) I'd like to know the short, medium, and long range goals, strategies, and
- tactics that Apple has concerning OO technology and MacApp. My decision to use
- MacApp includes both technical and strategic issues. The feeling that I get
- from Apple is that, as a developer of products for the Macintosh (an Apple
- "Partner"), I am important in their strategy. Apple has already made the
- decision that they would discuss future products and directions with developers
- when System 7 was announced over a year and a half ago. If I knew more about
- where Apple is going, I might even be able to help out with auxillary tools for
- MacApp. Without clear signals, though, I'm afraid to enter any domain that
- Apple currently touches. For example, I was close to completing a product that
- was terminated by others when Apple announced System 7. I really don't want to
- go through that again. I think the speculation about where Apple is going can
- be interesting and informative but can be exceedingly dangerous! I feel that
- the lack of information from Apple is causing the flock to stray.
-
- I feel that Apple could do more in keeping me informed of what it's doing
- without giving away the store. For example, it kinda sounds like the
- requirements and design of MacApp 3.0 have been decided but I don't recall them
- asking me what I thought should be included. Matter of fact, I don't recall a
- statement from Apple explaining the requirements and design. This causes me to
- think that I'm shut out of the planning process. One of the reasons for
- writing this KC burner is to let Apple know what I think anyway. Bear in mind
- that I don't think that suggestions I make have to be implemented. I would,
- however, like for Apple to solicit my opinions and let me know of the
- disposition (with reasons) of these suggestions. There doesn't have to be
- anything formal about it either. An informal message in a Link would be okay.
-
- I'm already on the MacApp bus but I'd like to know where it's headed.
-
- Stirring the pot with an outboard motor...
-
- I think I'm still,
- Dave Lucky
-
-